
%% bare_jrnl.tex
%% V1.3
%% 2007/01/11
%% by Michael Shell
%% see http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE journal paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/



% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/


%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
\documentclass[journal]{IEEEtran}
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[journal]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
%\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is Scott Pakin's eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.


%\ifCLASSOPTIONcaptionsoff
%  \usepackage[nomarkers]{endfloat}
% \let\MYoriglatexcaption\caption
% \renewcommand{\caption}[2][\relax]{\MYoriglatexcaption[#2]{#2}}
%\fi
% endfloat.sty was written by James Darrell McCauley and Jeff Goldberg.
% This package may be useful when used in conjunction with IEEEtran.cls'
% captionsoff option. Some IEEE journals/societies require that submissions
% have lists of figures/tables at the end of the paper and that
% figures/tables without any captions are placed on a page by themselves at
% the end of the document. If needed, the draftcls IEEEtran class option or
% \CLASSINPUTbaselinestretch interface can be used to increase the line
% spacing as well. Be sure and use the nomarkers option of endfloat to
% prevent endfloat from "marking" where the figures would have been placed
% in the text. The two hack lines of code above are a slight modification of
% that suggested by in the endfloat docs (section 8.3.1) to ensure that
% the full captions always appear in the list of figures/tables - even if
% the user used the short optional argument of \caption[]{}.
% IEEE papers do not typically make use of \caption[]'s optional argument,
% so this should not be an issue. A similar trick can be used to disable
% captions of packages such as subfig.sty that lack options to turn off
% the subcaptions:
% For subfig.sty:
% \let\MYorigsubfloat\subfloat
% \renewcommand{\subfloat}[2][\relax]{\MYorigsubfloat[]{#2}}
% For subfigure.sty:
% \let\MYorigsubfigure\subfigure
% \renewcommand{\subfigure}[2][\relax]{\MYorigsubfigure[]{#2}}
% However, the above trick will not work if both optional arguments of
% the \subfloat/subfig command are used. Furthermore, there needs to be a
% description of each subfigure *somewhere* and endfloat does not add
% subfigure captions to its list of figures. Thus, the best approach is to
% avoid the use of subfigure captions (many IEEE journals avoid them anyway)
% and instead reference/explain all the subfigures within the main caption.
% The latest version of endfloat.sty and its documentation can obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/endfloat/
%
% The IEEEtran \ifCLASSOPTIONcaptionsoff conditional can also be used
% later in the document, say, to conditionally put the References on a 
% page by themselves.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.





% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
%\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Generating Awesome Music Remotely in Java}
%
%
% author names and IEEE memberships
% note positions of commas and nonbreaking spaces ( ~ ) LaTeX will not break
% a structure at a ~ so this keeps an author's name from being broken across
% two lines.
% use \thanks{} to gain access to the first footnote area
% a separate \thanks must be used for each paragraph as LaTeX2e's \thanks
% was not built to handle multiple paragraphs
%

\author{Gabriel Haim,
        Andrew Moffat,
        Marcin Bujar,
        Rami Dmour,
        Jonathan Balkind
        (Group I)}% <-this % stops a space
%\thanks{M. Shell is with the Department
%of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta,
%GA, 30332 USA e-mail: (see http://www.michaelshell.org/contact.html).}% <-this % stops a space

% note the % following the last \IEEEmembership and also \thanks - 
% these prevent an unwanted space from occurring between the last author name
% and the end of the author line. i.e., if you had this:
% 
% \author{....lastname \thanks{...} \thanks{...} }
%                     ^------------^------------^----Do not want these spaces!
%
% a space would be appended to the last name and could cause every name on that
% line to be shifted left slightly. This is one of those "LaTeX things". For
% instance, "\textbf{A} \textbf{B}" will typeset as "A B" not "AB". To get
% "AB" then you have to do: "\textbf{A}\textbf{B}"
% \thanks is no different in this regard, so shield the last } of each \thanks
% that ends a line with a % and do not let a space in before the next \thanks.
% Spaces after \IEEEmembership other than the last one are OK (and needed) as
% you are supposed to have spaces between the names. For what it is worth,
% this is a minor point as most people would not even notice if the said evil
% space somehow managed to creep in.



% The paper headers
\markboth{Distributed Algorithms and Systems 4 -- University of Glasgow School of Computing Science}%
{}
% The only time the second header will appear is for the odd numbered pages
% after the title page when using the twoside option.
% 
% *** Note that you probably will NOT want to include the author's ***
% *** name in the headers of peer review papers.                   ***
% You can use \ifCLASSOPTIONpeerreview for conditional compilation here if
% you desire.




% If you want to put a publisher's ID mark on the page you can do it like
% this:
%\IEEEpubid{0000--0000/00\$00.00~\copyright~2007 IEEE}
% Remember, if you use this you must call \IEEEpubidadjcol in the second
% column for its text to clear the IEEEpubid mark.



% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle


\begin{abstract}
%\boldmath
Generating digital music in a manner reflecting that of a real
orchestra may not be considered a difficult problem in a single-system
context, but when approached in a distributed manner, new difficulties
surface regarding coordination and leadership, among others. In this
paper we describe Generating Awesome Music Remotely in Java (GAMRJ), a
distributed system implemented using Java RMI to simulate the music
production performed in a real-world orchestra. GAMRJ is designed to
utilise a number of distributed techniques, including timing, leader
election and fault tolerance, in order to provide functionality and
responsiveness.

We will describe the overall design of our system, the behaviour of
the peers in their music production and the synchronisation of those
peers to develop an adaptive global idea of time. Also covered are the
fault tolerance and music generation details, with much of the above
differing from existing systems in the literature. Having performed an
evaluation, we found GAMRJ to be responsive to tempo changes and
resilient to failures of musicians, though it relies on redundancy to
do so. We identified a number of areas of improvement, from music
representation to connection topology which have been left for future
work.
\end{abstract}


% Note that keywords are not normally used for peerreview papers.
\begin{IEEEkeywords}
Java, RMI, fault-tolerant, distributed, GAMRJ, orchestra, music.
\end{IEEEkeywords}



\IEEEpeerreviewmaketitle



\section{Introduction}

\IEEEPARstart{W}{hile} distributed systems often focus on very applied
or large scale tasks, it is interesting to see how distributed systems
concepts can be applied to smaller scale problems. The generation of
music on a single system is one such problem and comes with a number
of subtleties which must be considered. Using the model of a
real-world orchestra, we created a distributed music generation system
named “Generating Awesome Music Remotely in Java” (GAMRJ). This
real-world model showed us a number of parallels between the physical
group of players and their interactions, and distributed systems
concepts.

Generating Awesome Music Remotely in Java (GAMRJ) is a system which
makes use of Java’s Remote Method Invocation API to simulate an
orchestra consisting of a single conductor system and a number of
players who are connected in a clique peer-to-peer fashion. In an
orchestra, timing is key to the playing of music and any system which
wishes to simulate this functionality must have a carefully defined
global idea of time. GAMRJ uses an interesting approach, similar to
vector clocks, in order to synchronise play from the conductor’s
actions in a manner similar to what would occur in the real world,
with the systems never exchanging time in an exact form, contrary to
the that of the Network Time Protocol (NTP). When tempo changes are
introduced to the music, the conductor’s synchronisation calls to the
clients become more or less frequent and as such the clients adapt to
the new rate of play based on the differences in the time of
synchronisation calls for recent bars.

Fault tolerance is an important problem in a distributed system and
GAMRJ tackles this in a way that does not follow the usual behaviour
of an orchestra, instead using successive leader elections to find new
players to replace the main conductor of the system. At the moment,
GAMRJ uses redundancy to survive player failures, with further
tolerance to those faults left as future work.

Existing systems such as those detailed in [1] and [2] follow
different models or do not use the same technologies (ie. RMI) as we
chose to use. While we were restricted to using RMI, we feel that its
use does not eclipse the novelty of our design, rather it enhances it
as there are no existing systems in the literature developed using RMI
to achieve the same goals.

The paper begins by outlining our system design and the interaction
between the main Repository, Player and Conductor components. This is
followed by more specific implementation information, detailing our
realisation of the design and our handling of concurrency, among other
lower level details. We have also included a short evaluation of our
system’s performance, in particular the tolerance of faults and the
smooth operation of the system following player and conductor
failures. The final sections of the paper cover the related work from
the literature and how it relates to our system, as well as future
extensions or adaptations that could be made to GAMRJ.


\section{System Design}

In order for the system to act as a distributed orchestra, the overall
functionality needs to be spread across a set of nodes. Most of these
will act as the musicians, and one will take the role of the
conductor. The musician nodes should be able to play arbitrary
sequences of notes, so that together they can each perform a part of
an orchestral piece. The playback needs to be synchronised across all
of the nodes by the conductor node so that the overall output is
coherent and pleasant to the listener. The conductor node is therefore
critical to the correct functioning of the system. This means the
system should be able to handle an arbitrary failure of the conductor
and replace it with another node in the orchestra. Finally, all the
nodes need to have the correct information about the current music
piece being played.

\subsection{Client}

The client encapsulates functionality of both a musician and a
conductor node. Each client offers a remote interface called Monitor,
through which it can be reached by other nodes in the orchestra. The
MonitorImpl class implements this interface and is responsible for
managing the state of the node. It decides whether it will act as a
musician (Player class) or a conductor (Conductor class). This
decision is made through a leader election process, in which a
conductor is chosen from the set of nodes. This functionality is
described in detail in Section(impl). Figure~\ref{fig:client} shows
how these classes are related.

The Player and Conductor classes implement functionality which allows
them to communicate with one another. Conductor class is responsible
for maintaining the current tempo of the song, and periodically
contacting the Player nodes (through their Monitor interfaces) so that
they can remain in sync. The Player class in turn implements
functionality to allow it to decide which part of the song to play
next, and how fast. Finally, the Oscillator class is responsible for
playing out the requested sound to the local sound card. It is called
by the local Player object, which provides the properties of the music
sample to be played, based on synchronisation data received from the
current conductor.

\begin{figure}[!t]
\centering
\includegraphics[width=3in]{uml/client.pdf}
\caption{Class diagram of the client package}
\label{fig:client}
\end{figure}


\subsection{Repository}

The repository is a single source of music data which all musician
nodes (the clients) in the orchestra access and obtain music
information for their particular instrument. One musical piece
therefore holds information for each of the instruments in the
orchestra, such as the notes that need to be played, in which octave,
and for how long. The repository is responsible for storing this
information and making it available for the conductor node as well as
all the client nodes.

\begin{figure}[!t]
\centering
\includegraphics[width=3in]{uml/repository.pdf}
\caption{Class diagram of the repository package}
\label{fig:repo}
\end{figure}

As shown in Figure~\ref{fig:repo}, the repository is composed of a remote
interface, which allows it to be contacted by the musicians and the
conductor using RMI calls. Additional helper classes are included to
implement loading and parsing of music data.


\section{Implementation}

As mentioned previously the system has been implemented in Java, and
all the distributed functionality is realised using Java Remote Method
Invocation (RMI). This section describes in detail how the system
components, functionality, and design decisions were realised.

\subsection{Client}

\subsubsection{Monitor}

The system implements a leader election the system based on the bully
algorithm described by Coulouris, Dollimore and Kindberg[4]. The
monitor which handles either the conductor or the player also handles
the leader election.

The implementation of Monitor possesses many fields to handle the
election correctly:

\begin{itemize}
\item ArrayList of musicians addresses/monitors:\\ This list represent
  all the musicians performing and is sorted by order of importance of
  the musicians. This list is constructed from the musicians.txt file
  when the system is launched.

\item Actual conductor address:\\ Store the conductor address which is
  removed from the musicians list.

\item Boolean electionIsPerforming:\\ Says if an election is
  performing, used for the main algorithm.
\end{itemize}


First election.\\ When first run, each monitor reads the list of
musicians. This list being previously ordered, the first election is
fake; the last monitor on the list launches a conductor thread, with
the others launching player threads. Each monitor waits (calling the
join method) on its conductor or player’s thread for the end of the
song or a premature termination (if something goes wrong and an
emergency election is necessary).

Conductor failure detection.\\ The conductor performs synchronisation
with all the players (through their Monitors) on a regular basis. Each
player thread computes an average waiting time based on all previous
synchronisation times. If the wait for the next sync is far superior
to this time, the player considers the conductor to have failed and
prompts an early termination of its thread, leading the monitor to
call an election.

Emergency election in case of failure.\\ The main algorithm of the
emergency election is an implementation of that described in [4]. The
Monitor interface requires three methods which corresponds to the
three types of messages used in this algorithm : coordinator, election
and answer messages.  The algorithm works in two phases. If the
monitor calling the election is the least important musician (the last
on the ordered list), it bullies itself to be the new conductor
sending conductor messages to all others players threads. If not, it
sends election message to all others player threads less important
than him (after him on the ordered list) and waits for someone to
answer and bully itself into the new conductor. If nothing is
answering the election message, the process considered all the less
important musicians down and bullies itself into the conductor.

\subsection{Conductor}

Once a Monitor instantiates a Conductor thread and some time has
passed (in this case 5 seconds), it starts sending synchronisation
messages to all other Player objects in the orchestra (forwarded
through their Monitor interfaces) containing the current bar to be
played. The first four messages do not result in any music being
played by the musicians, but are sent so that they can determine the
starting tempo of the song. The conductor makes random changes in the
tempo, which affect the playback speed of the musicians. It also
determines the time taken to send messages to all players, and
subtracts this from the time between sync messages, in order to
improve timing performance. The conductor terminates once the song is
complete (based on information from the repository).

\subsection{Player}

When a Monitor creates a new Player thread, it first obtains the music
to be played from the repository. Once that is complete it starts
receiving synchronisation messages from the Conductor. Based on their
timing, it uses Exponential Moving Average to determine the average
playback time of one bar. This allows the music to remain in sync as
the tempo set by the conductor is changing.

\subsection{Repository}

The repository code consists of two main parts: that for interfacing
with the rest of the system; and that for parsing an xml file
containing the music data for all possible instruments.

\subsubsection{Parsing}
Each xml file contains one song, split into separate sections for
every instrument.  The song tag itself contains attributes for the
length of the song, in bars, and the number of instruments included.
The instrument sections are further subdivided into bars.  These bars
represent the those present in a traditional music score and aid the
conductor in synchronisation.  This is as synchronisation per-beat
would be too frequent overhead-wise, and a longer synchronisation
period would result in mismatches in tempo.

When a repository is initialised the user is asked to input the name
of the file from which music will be read.  This file is then read
immediately, storing the music in a hashtable, indexed by instrument
number, and the song length and number of instruments as simple
integers.  A SAX parser is used due to the small size of the music
files.

\subsubsection{Interface}
The interface to the rest of the system is relatively simple,
providing methods for retrieving the song length and music for a
specific instrument.  These are for use by the conductor and players,
respectively.  Music is passed as a list of a list of notes, with the
first list consisting of a set of bars, each bar being a list of
notes.  As bars are merely used to allow for easier timing
synchronisation it was decided not to create a class for them.

The repository is initially used when nodes are starting up and
retrieving music.  Should the system function optimally it will not be
used again.  In the case of a conductor failure and a subsequent
leader election being performed, however, all the instrument players
restart and as such need to re-query the repository for the music they
should be playing. The new conductor must also query for the song
length.

\section{Evaluation}

In order to test how valuable GAMRJ is as a usable system, we
performed a number of informal tests relating to timing and fault
tolerance, the two main metrics we aimed to show good performance
in. While the most important test relating to leader election did not
succeed, we saw promise with the other tests and associated the
failure of leader election down to a programming failure which was
unable to be fixed by the time of printing.

The first evaluation we performed probed the functionality of the
client machines when it came to tempo synchronisation with the
conductor. By adding a random change to the conductor’s provided tempo
every 8 bars, the client must change its own perceived tempo from the
previous one. As round-trip times and the time for the conductor to
contact all of the players may vary, the player uses an exponential
moving average of the recent bar times in order to update its idea of
current tempo from the conductor.  By checking the average bar lengths
determined by the player, we found that there was a quick response to
the tempo changes and we predict that if successive tempo changes were
to occur in one direction (ie. only increasing or only decreasing),
then the player should provide a very smooth change in tempo. This
behaviour is more similar to a real orchestra and without the
exponential moving average, we would expect a more discretely
increasing/decreasing jump in tempos.

The second evaluation we followed tested the fault tolerance methods
implemented in GAMRJ. To begin with, we connected more players to the
system than there were musicians in the chosen music file and allowed
multiple players to play the same instrument’s music. Upon
disconnection of players that were duplicating instruments, we found
that the system did not suffer any major failure, with only an extra
warning message being produced by the conductor when it attempted to
update the relevant player.  The second piece of this test required us
to run GAMRJ players on at least 3 machines and after the
synchronisation stage, kill the conductor which had been originally
chosen. After 20 seconds of no synchronisation updates (this can be
changed to improve speed of recovery), the clients would identify a
conductor failure and initialise the new leader election
process. Unfortunately, while the players detected the conductor
failure and initialised the leader election process, a bug in the
implementation which had previously gone undetected caused the clients
involved to fail. A secondary problem is that the clients do not
inform the the conductor of where to restart in the music, due again
to a mistake in the implementation.

While the latter part of the evaluation was important and we were
unable to gain useful feedback from carrying it out, we hope that with
further checking of the code and only some minor changes, it would be
possible to carry out the leader election after conductor failures as
expected.


\section{Related Work}

Having searched the literature for related systems, we found GAMRJ to
be very much novel in its organisation model and its use of RMI, with
previous research into distributed music generation focusing on
different music production models. Also relevant to our search were
systems for music representation, as we had developed our own
representation for the music repository from which the players collect
the music they were to play.

The most common model seen elsewhere saw music being produced at a
number of musician nodes who would then send that music by multicast
to all other musician nodes. All musician nodes would then combine
their own music and the music they had received and play it together,
without any need for central coordination by some form of
conductor. The main aim was to provide fast distribution of music
produced by musicians, in order that all musicians could play music
that would sound as similar as possible.

This approach is the one taken by Bonafous et al.[1] in the
development of their Distributed Virtual Orchestra Project. Their
system was designed to play music synchronously and as such had to
make use of a number of lower-level and domain-specific tools which
may not have been suitable for our system, such as the JMax visual
programming environment for multimedia systems. One key feature of
their system which is of particular interest to us, however, is the
use of multicast IP. As our system makes use of the same network
topology (a fully-connected graph), we would be interested to see what
performance improvements could be gleaned by a move to some multicast
RPC system.

The Unstoppable Orchestra[2] features a very similar design to GAMRJ,
with a number of interesting techniques. In order to maximise fault
tolerance, one musician may take over the playing from another which
has failed, hence playing 2 or more instruments from that point
on. This system also features an initial synchronisation of time,
rather than the continuous model like our own, therefore removing any
need for a conductor. Both of these differences could be seen as areas
of future work.

As noted above, music representation was of interest in our research
and one important piece of related work was the MusicXML music score
representation[3]. MusicXML, as the name suggests, stores
score-specific information in xml files, making them easy to parse
through standard means such as SAX. GAMRJ also uses XML files and a
SAX parser, but it does not conform to the MusicXML
representation. This was mainly due to time constraints and the fact
we are not attempting to develop a true production system. Adaptations
of the representation are left for future work, as our current focus
is on the music generation and distributed aspects.



\section{Future Work}

Having developed the system to a working level of functionality and
observed the other systems detailed in the literature, we have a
number of possible future extensions or adaptations in mind that could
improve GAMRJ. These ideas cover leader election, fault tolerance and
music generation, among other areas.

While the bully algorithm for leader election fits our system well, it
would be interesting to attempt to implement other leader election
algorithms. Of particular interest is the Chang and Roberts
algorithm[5], which links nodes in a ring and uses message passing in
one direction to determine who the next leader would be. While this
approach would affect the topology of the network of connections
between nodes, it could provide insights into other ways of organising
the peers topology-wise. The implementation of this algorithm would
focus mainly on the performance impact when the conductor fails. It is
hoped that if we implemented this as an alternative to the bully
algorithm that we could measure the differences in restart time upon
that failure.

As mentioned above, the implementation of the Chang and Roberts
algorithm would affect the topology of our network. At the moment the
peers form a fully-connected network, but it would be interesting to
explore other topologies which might give different functionality and
performance. For example, bully election does not require a
fully-connected network and in fact the conductor is the only node
which really needs to be connected to all others. If we were to
attempt a less connected structure (for example something as minimum
as a spanning tree), there could be problems if the conductor were a
central node, as this would split the nodes into multiple forests. A
possible solution could be to use the music repository to collect the
nodes in the network that have connected so far, at the time of music
retrieval. This would mean nodes which collected later would know all
of the nodes in the network, and they might then be treated
preferentially for election (lateness to collect music could then be
the metric by which bully election would occur). This solution would
also remove the need for a text file containing all of the nodes that
are to exist in the network.

GAMRJ musician machines currently produce sound by pushing sine waves
directly to the sound buffer, which is a very low-level method for
music generation. As Java has support for midi through its own and
third-party packages, we feel it wouldn’t be an onerous task to add
support for midi or other music generation techniques to the Players
in the system. This would give better quality audio and the ability to
reflect real instruments which play in an orchestra. MIDI files are
also usually very small in size and so network overhead should remain
minimal.

As fault tolerance is central to GAMRJ, we would be keen to develop
our model further to take account of more faults that may occur in the
system. At the moment if a player disconnects they will not be
replaced until the conductor also fails and a new election is
called. It may be of interest to our purpose to either call a new
election for all tasks or within players. At this point, one peer
could take up the role of multiple players or a “low-priority” player
could be removed from the orchestra, taking with it that part of the
piece. In the case that there are multiple peers already playing the
same instrument, their part of the music is of course less likely to
disappear, meaning that our current GAMRJ implementation is mostly
suitable for collections of systems that number greater than the
number of instruments playing in a piece.

As mentioned in our related work, we could improve the music
representation in the repository to conform with either MusicXML or
another standard. As our system already uses an XML representation,
this is again a change which should not be particularly complex to
implement. by conforming to this standard we would likely be able to
utilise packages developed by others to read and play MusicXML
files. If we were to go down the path of generating music using MIDI
then we could also make use of a wide range of existing packages for
representation and play of MIDI music.

Of course for the end-user, an important part of the system is its
user interface. While GAMRJ currently works from the command-line we
could easily produce a graphical user interface, using Swing or
another windowing-toolkit, which would launch from a Java archive
file. This could allow the user to see which instrument their system
was playing, who the conductor was and if there were any problems with
the current state of the system. This network overview and management
may be a somewhat difficult task to implement as it could require more
network traffic overhead and the utilisation of full-connectedness
(although that is the current state of our system).


\section{Conclusion}

GAMRJ is a distributed music generation system designed to reflect the
operation of a real-world orchestra. With a conductor which provides
synchronisation to a number of music players, the system aims to
provide timing and fault-tolerance guarantees, backed by a mechanism
akin to vector clocks and the bully leader election algorithm,
respectively. As GAMRJ is implemented using Java RMI for its
distribution aspect, it shows a new approach to the problem of
distributed music generation versus that found in the
literature. While our evaluation showed smooth transitions in music
tempo changes and fault tolerance to player failures through
redundancy, the main fault tolerance mechanism of leader election was
not possible due to programmer errors. In future we would like to
address this issue and provide a number of improvements as detailed
above, hopefully adding extensively to the novelty of our system.



% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operation of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}



% Note that IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command, the
% \label for the overall figure must come after \caption.
% \hfil must be used as a separator to get equal spacing.
% The subfigure.sty package works much the same way, except \subfigure is
% used instead of \subfloat.
%
%\begin{figure*}[!t]
%\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
%\label{fig_second_case}}}
%\caption{Simulation results}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.


% An example of a floating table. Note that, for IEEE style tables, the 
% \caption command should come BEFORE the table. Table text will default to
% \footnotesize as IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that IEEE does not put floats in the very first column - or typically
% anywhere on the first page for that matter. Also, in-text middle ("here")
% positioning is not used. Most IEEE journals use top floats exclusively.
% Note that, LaTeX2e, unlike IEEE journals, places footnotes above bottom
% floats. This can be corrected via the \fnbelowfloat command of the
% stfloats package.





% if have a single appendix:
%\appendix[Proof of the Zonklar Equations]
% or
%\appendix  % for no appendix heading
% do not use \section anymore after \appendix, only \section*
% is possibly needed

% use appendices with more than one appendix
% then use \section to start each appendix
% you must declare a \section before using any
% \subsection or using \label (\appendices by itself
% starts a section numbered zero.)
%


%\appendices
%\section{Proof of the First Zonklar Equation}
%Appendix one text goes here.

% you can choose not to have a title for an appendix
% if you want by leaving the argument blank
%\section{}
%Appendix two text goes here.


% use section* for acknowledgement
%\section*{Acknowledgment}



% Can use something like this to put references on a page
% by themselves when using endfloat and the captionsoff option.
\ifCLASSOPTIONcaptionsoff
  \newpage
\fi



% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
\begin{thebibliography}{9}

\bibitem{virtual} Remy Bonafous, Nicolas Bouillot, Hans-Nikolas
  Locher, Joel Berthelin, Francois Dechelle, and Eric Gressier-Soudan
  \emph{The Distributed Virtual Orchestra Project},\\ CEDRIC
  Laboratory, CNAM, 292 rue St Martin

\bibitem{unstoppable} Werner, M. and Polze, A. and Malek, M. \emph{The
  unstoppable orchestra: A responsive distributed application},\\
  Configurable Distributed Systems, 1996. Proceedings., Third
    International Conference on, p154--160

\bibitem{xml} Michael Good \emph{MusicXML for Notation and
  Analysis},\\ Recordare LLC, PO Box 3459, Los Altos, CA 94024

\bibitem{dasbook} G. Coulouris, J. Dollimore and T. Kindberg,
  \emph{Distributed Systems: Concepts and Design},\\ Addison Wesley,
  2005.

\bibitem{chang} E. Chang; R. Roberts \emph{An improved algorithm for
  decentralized extrema-finding in circular configurations of
  processes},\\ 1979 Communications of the ACM (ACM) 22 (5): p281--283

\end{thebibliography}

% biography section
% 
% If you have an EPS/PDF photo (graphicx package needed) extra braces are
% needed around the contents of the optional argument to biography to prevent
% the LaTeX parser from getting confused when it sees the complicated
% \includegraphics command within an optional argument. (You could create
% your own custom macro containing the \includegraphics command to make things
% simpler here.)
%\begin{biography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{mshell}}]{Michael Shell}
% or if you just want to reserve a space for a photo:

%\begin{IEEEbiography}{Michael Shell}
%Biography text here.
%\end{IEEEbiography}

% if you will not have a photo at all:
%\begin{IEEEbiographynophoto}{John Doe}
%Biography text here.
%\end{IEEEbiographynophoto}

% insert where needed to balance the two columns on the last page with
% biographies
%\newpage

%\begin{IEEEbiographynophoto}{Jane Doe}
%Biography text here.
%\end{IEEEbiographynophoto}

% You can push biographies down or up by placing
% a \vfill before or after them. The appropriate
% use of \vfill depends on what kind of text is
% on the last page and whether or not the columns
% are being equalized.

%\vfill

% Can be used to pull up biographies so that the bottom of the last one
% is flush with the other column.
%\enlargethispage{-5in}



% that's all folks
\end{document}


